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Abstract 

A  set  of  CASE  tools  is  described  for  developing  for¬ 
mal  requirements  specifications  expressed  in  the  SCR 
(Software  Cost  Reduction)  tabular  notation.  The  tools 
include  an  editor  for  building  the  specifications,  a  con¬ 
sistency  checker  for  testing  the  specifications  for  con¬ 
sistency  with  a  formal  requirements  model,  a  simula¬ 
tor  for  symbolically  executing  the  specifications,  and  a 
verifier  for  checking  that  the  specifications  satisfy  se¬ 
lected  application  properties.  As  background,  the  SCR 
method  for  specifying  requirements  is  reviewed,  and  a 
formal  requirements  model  is  introduced.  Examples  are 
presented  to  illustrate  the  tools. 

1  Introduction 

High  assurance  computer  systems  are  computer  sys¬ 
tems  where  compelling  evidence  is  required  that  the 
system  delivers  its  services  in  a  manner  that  satisfies 
certain  critical  properties.  Examples  of  high  assur¬ 
ance  systems  include  military  command  and  control 
systems,  nuclear  power  plants,  telephone  networks, 
medical  systems  (e.g.,  patient  monitoring  systems), 
air  traffic  control  systems,  and  flight  control  systems. 
Critical  properties  that  such  systems  must  enforce  in¬ 
clude  security  properties,  which  prevent  unauthorized 
disclosure,  modification,  and  withholding  of  sensitive 
information  (see,  e.g.,  [11]);  safety  properties,  which 
prevent  unintended  events  that  result  in  death,  injury, 
illness,  or  damage  to  or  loss  of  property;  and  real-time 
properties,  which  require  the  system  to  deliver  its  re¬ 
sults  within  specified  time  intervals  (see,  e.g.,  [18]). 

A  promising  approach  for  building  high  assurance 
systems  is  to  apply  formal  methods.  According  to  a  re¬ 
cent  study,  formal  methods  are  “beginning  to  be  used 
seriously  and  successfully  by  industry.  ..  to  develop 
systems  of  significant  scale  and  importance”  [6].  Es¬ 
pecially  important  for  developing  high  assurance  sys¬ 
tems  are  formal  methods  for  specifying  requirements. 
Studies  have  shown  that  a  large  portion  of  the  most  se¬ 
rious  errors  in  safety-critical  systems  are  requirements 


errors  (see,  e.g.,  [19]).  Formal  specification  can  reduce 
requirements  errors  by  reducing  ambiguity  and  impre¬ 
cision  and  by  making  instances  of  inconsistency  and 
incompleteness  obvious.  Given  a  formal  requirements 
specification,  formal  analysis  can  detect  many  classes 
of  errors,  some  automatically. 

One  of  the  12  methods  included  in  the  above  study 
is  the  Software  Cost  Reduction  (SCR)  requirements 
method.  Introduced  originally  to  describe  the  func¬ 
tional  requirements  of  software  precisely  and  unam¬ 
biguously  [15,  16],  the  SCR  method  has  been  extended 
recently  to  describe  system,  rather  than  simply  soft¬ 
ware,  requirements  and  to  represent  both  functional 
and  nonfunctional  (e.g.,  timing  and  accuracy)  require¬ 
ments  [21,  24].  Designed  for  use  by  engineers,  the  SCR 
method  has  been  applied  successfully  to  a  number  of 
practical  systems,  including  the  A- 7  aircraft’s  Oper¬ 
ational  Flight  Program  [15,  1];  a  submarine  commu¬ 
nications  system  [14];  and  safety-critical  components 
of  two  nuclear  power  plants,  the  Darlington  plant  in 
Canada  [22]  and  a  second  plant  in  Belgium  [5].  More 
recently,  a  version  of  the  SCR  method  called  CoRE  [8] 
was  used  to  document  the  requirements  of  Lockheed’s 
C-130J  Operational  Flight  Program  [9]. 

While  the  above  applications  of  the  SCR  method 
rely  on  manual  techniques,  effective  use  of  the  method 
in  industrial  settings  requires  powerful,  robust  tool 
support.  As  observed  in  the  formal  methods  study 
[6],  tool  support  for  formal  methods,  though  currently 
weak  and  impoverished,  must  be  “an  integral  part  of 
a  broader  software  development  tool  suite.”  Further, 
one  of  the  original  developers  of  the  SCR  method  and 
a  leader  in  the  certification  of  the  Darlington  software 
cites  the  need  for  tool  support  to  make  formal  methods 
“practical”  [22]. 

An  important  question  is  what  form  tool  support 
should  take.  To  answer  this  question,  our  group  is 
developing  a  prototype  toolset,  called  SCR*,  for  con¬ 
structing  and  analyzing  formal  requirements  specifica¬ 
tions.  The  toolset,  which  is  coded  in  C++  and  runs 
on  SPARC  workstations,  includes  a  specification  edi¬ 
tor  for  building  and  displaying  the  requirements  spec- 
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ifications,  a  simulator  for  symbolically  executing  the 
specifications,  and  formal  analysis  tools  for  testing  the 
specifications  for  selected  properties. 

One  analysis  tool,  called  a  consistency  checker  [10], 
tests  a  requirements  specification  for  properties  de¬ 
rived  from  our  formal  requirements  model  [12].  Be¬ 
cause  the  requirements  model  describes  the  prop¬ 
erties  that  all  SCR-style  requirements  specifications 
must  satisfy,  the  properties  tested  by  the  consistency 
checker  are  independent  of  a  particular  application. 
These  properties  are  usually  quite  simple.  They  in¬ 
clude  proper  syntax,  type  correctness,  completeness 
(e.g.,  no  missing  cases),  and  deterministic  behavior. 
A  second  analysis  tool,  called  a  verifier,  checks  the 
specification  for  critical  application  properties,  such 
as  safety  properties,  timing  properties,  and  security 
properties.  Because  verification  of  application  proper¬ 
ties  depends  on  a  consistent  (and  complete)  require¬ 
ments  specification,  analysis  using  a  verifier  logically 
follows  analysis  with  a  consistency  checker. 

An  industrial-strength  formal  method  should  have  a 
formal  (that  is,  mathematical)  foundation  and  should 
be  usable  by  engineers,  scalable,  and  cost-effective. 
The  tools  described  in  this  paper  are  an  important 
component  of  such  a  method  for  requirements  speci¬ 
fication.  They  have  a  formal  foundation,  namely,  our 
requirements  model  [12].  They  are  easy  to  use:  after 
developing  a  requirements  specification  in  the  SCR  no¬ 
tation,  the  engineer  uses  the  tools  to  analyze  the  spec¬ 
ification  automatically  and  to  execute  it  symbolically. 
They  should  scale  up  to  handle  practical  applications: 
in  two  experiments,  our  tools  detected  several  signifi¬ 
cant  errors  in  a  moderate-size  requirements  specifica¬ 
tion  [13].  This  evidence  coupled  with  the  high  cost 
(several  million  dollars)  of  the  Darlington  certification 
effort,  where  error  checking  was  done  by  hand,  sug¬ 
gests  that  the  tools  are  cost-effective. 

The  purpose  of  this  paper  is  to  introduce  our 
toolset  and  the  formal  requirements  model  that  pro¬ 
vides  its  semantics.  Section  2  reviews  the  SCR  require¬ 
ments  method  and  introduces  an  example  to  illustrate 
the  method.  Section  3  summarizes  our  requirements 
model.  Sections  4-7  describe  the  specification  editor, 
consistency  checker,  simulator,  and  verifier  that  make 
up  our  toolset.  Sections  8  and  9  describe  related  work 
and  a  process  for  developing  requirements.  Finally, 
Section  10  contains  our  conclusions. 

2  Review  of  the  SCR  Method 

Background.  The  purpose  of  a  requirements  docu¬ 
ment  is  to  describe  all  acceptable  system  implemen¬ 
tations  [14].  To  demonstrate  a  systematic  method 


for  achieving  this,  the  software  requirements  docu¬ 
ment  for  the  A- 7  aircraft’s  Operational  Flight  Program 
was  published  in  1979.  This  document  introduces 
many  features  associated  with  the  SCR  requirements 
method — the  tabular  notation,  the  underlying  finite 
state  machine  model,  and  special  constructs  for  speci¬ 
fying  requirements,  such  as  conditions  and  events,  in¬ 
put  and  output  data  items,  mode  classes,  and  terms. 
Recently,  a  number  of  researchers,  including  Faulk 
[7,  8,  9],  van  Schouwen  [24,  25],  and  Parnas  [21],  have 
extended  and  refined  the  original  SCR  method  and 
strengthened  the  method’s  formal  foundation. 

Faulk’s  thesis  in  1989  [7]  provided  formal  definitions 
for  parts  of  the  A- 7  model.  In  particular,  it  described 
the  condition  tables  as  total  functions  and  the  mode 
classes  as  finite  state  machines  defined  over  events. 
A  deficiency  in  the  original  A- 7  document  is  that  a 
mode  class  may  be  undefined  in  certain  states;  e.g., 
if  no  weapon  was  allocated,  the  Weapons  mode  class 
was  undefined.  Faulk’s  model  requires  a  mode  class  to 
be  defined  in  every  state;  e.g.,  when  no  weapon  is  allo¬ 
cated,  the  Weapons  mode  class  is  in  mode  Hone.  This 
not  only  makes  analysis  of  the  specifications  more  ef¬ 
ficient;  using  mode  classes  to  partition  the  state  space 
also  reduces  the  amount  of  detail,  thus  making  the 
specifications  easier  to  understand. 

In  1990,  van  Schouwen’s  thesis  [24]  presented  a 
system-level  requirements  specification,  also  based  on 
the  A- 7  model,  for  the  Water  Level  Monitoring  System 
(WLMS),  part  of  the  shutdown  system  for  a  nuclear 
power  plant.  The  WLMS  specification  extends  the 
SCR  method  from  software  requirements  to  system 
requirements  and  demonstrates  the  use  of  the  method 
to  describe  a  system’s  functional  requirements  as  well 
as  its  precision  and  timing  requirements. 

In  1991,  Parnas  and  Madey  introduced  the  Four 
Variable  Model  [21],  which  formalizes  the  innovations 
in  van  Schouwen’s  thesis.  The  model,  illustrated  in 
Figure  1,  describes  the  required  system  behavior  in 
terms  of  quantities  in  the  system’s  environment. 

Four  Variable  Model.  The  Four  Variable  Model  de¬ 
scribes  the  required  system  functions,  timing,  and  ac¬ 
curacy  as  a  set  of  mathematical  relations  on  four  sets 
of  variables — monitored  and  controlled  variables  and 
input  and  output  data  items.  A  monitored  variable 
represents  an  environmental  quantity  that  influences 
system  behavior,  a  controlled  variable  an  environmen¬ 
tal  quantity  that  the  system  controls.  A  black  box 
specification  of  required  behavior  is  given  as  two  re¬ 
lations,  REQ  and  NAT,  from  the  monitored  to  the 
controlled  quantities.  NAT,  which  defines  the  set  of 
possible  values,  captures  any  natural  constraints  on 
the  system  behavior,  such  as  those  imposed  by  physi- 


Figure  1:  Four  Variable  Model. 

cal  laws  and  by  the  system  environment.  REQ  defines 
additional  constraints  on  the  system  to  be  built  as 
relations  the  system  must  maintain  between  the  mon¬ 
itored  and  the  controlled  quantities. 

In  the  Four  Variable  Model,  input  and  output  data 
items,  which  represent  the  system’s  input  and  output 
devices,  are  treated  as  resources.  Input  data  items 
(e.g.,  sensors)  are  resources  available  to  the  system  to 
sample  the  monitored  quantities.  The  relation  IN  de¬ 
fines  the  mapping  from  the  monitored  quantities  to 
the  input  data  items.  Similarly,  the  relation  OUT  de¬ 
fines  the  mapping  from  the  output  data  items  to  the 
controlled  quantities.  The  use  of  monitored  and  con¬ 
trolled  quantities,  rather  than  input  and  output  data 
items,  to  define  required  behavior  keeps  the  specifi¬ 
cation  in  the  problem  domain  and  allows  a  simpler 
specification. 

Like  the  Four  Variable  Model,  our  requirements 
model  can  be  used  to  describe  both  system  require¬ 
ments  and  software  requirements.  The  former  are 
described  by  defining  REQ,  the  required  relation  be¬ 
tween  the  monitored  and  controlled  variables,  the  lat¬ 
ter  by  describing  SOFTREQ1,  the  required  relation 
between  the  input  and  output  data  items.  Thus,  where 
appropriate,  we  use  the  term  input  variable  to  repre¬ 
sent  either  a  monitored  variable  or  an  input  data  item 
and  the  term  output  variable  to  represent  either  a  con¬ 
trolled  variable  or  an  output  data  item. 

The  next  section  reviews  the  constructs  and  tabu¬ 
lar  notation  used  in  SCR  requirements  specifications 
in  terms  of  the  Four  Variable  Model.  Because  our  ini¬ 
tial  requirements  model  emphasizes  the  system’s  func¬ 
tions,  the  discussion  focuses  on  aspects  of  the  Four 
Variable  Model  that  describe  functional  behavior. 

SCR  Constructs.  To  specify  the  relations  of  the 
Four  Variable  Model  in  a  practical  and  efficient  man¬ 
ner,  four  other  constructs,  all  introduced  in  the  A- 
7  requirements  document  [15],  are  useful.  These  are 
modes,  terms,  conditions,  and  events.  A  mode  class  is 
a  state  machine,  whose  states  are  called  system  modes 
(or  simply  modes)  and  whose  transitions  are  triggered 
by  events.  Complex  systems  are  defined  by  more  than 

1In  the  Four  Variable  Model,  SOFT  represents  the  software 

implementation;  by  SOFTREQ,  we  mean  the  software  require¬ 
ments  specification. 


Figure  2:  Requirements  Spec,  for  Safety  Injection. 

one  mode  class,  operating  in  parallel.  A  term  is  any 
function  of  input  variables,  modes,  or  other  terms  that 
helps  make  the  specification  concise.  A  condition  is  a 
predicate  defined  on  one  or  more  system  entities  (a 
system  entity  is  an  input  or  output  variable,  mode,  or 
term)  at  some  point  in  time.  An  event  occurs  when 
any  system  entity  changes  value.  A  special  event, 
called  an  input  event,  occurs  when  an  input  variable 
changes  value.  Another  special  event,  called  a  condi¬ 
tioned  event,  occurs  if  an  event  occurs  when  a  specified 
condition  is  true. 

To  illustrate  the  SCR  constructs,  we  consider  a  sim¬ 
plified  version  of  the  control  system  for  safety  injec¬ 
tion  described  in  [5].  The  system  uses  three  sensors  to 
monitor  water  pressure  and  adds  coolant  to  the  reac¬ 
tor  core  when  the  pressure  falls  below  some  threshold. 
The  system  operator  blocks  safety  injection  by  turn¬ 
ing  on  a  “Block”  switch  and  resets  the  system  after 
blockage  by  turning  on  a  “Reset”  switch.  Figure  2 
shows  how  SCR  constructs  could  be  used  to  specify 
the  requirements  of  the  control  system.  Water  pres¬ 
sure  and  the  “Block”  and  “Reset”  switches  are  rep¬ 
resented  as  monitored  variables,  WaterPres,  Block, 
and  Reset;  safety  injection  as  a  controlled  variable, 
Safety  Inj  ection;  each  sensor  as  an  input  data  item; 
and  the  hardware  interface  between  the  control  system 
software  and  the  safety  injection  system  as  an  output 
data  item. 

The  specification  illustrated  in  Figure  2  includes  a 
mode  class  Pressure,  a  term  Overridden,  and  several 
conditions  and  events.  The  mode  class  Pressure,  an 
abstract  model  of  the  monitored  variable  WaterPres, 
contains  three  modes,  TooLow,  Permitted,  and  High. 
At  any  given  time,  the  system  must  be  in  one  of 
these  modes.  A  drop  in  water  pressure  below  a  con¬ 
stant  Low  causes  the  system  to  enter  mode  TooLow;  an 
increase  in  pressure  above  a  larger  constant  Permit 
causes  the  system  to  enter  mode  High.  The  term 
Overridden  is  true  if  safety  injection  is  blocked,  false 
otherwise.  An  example  of  a  condition  in  the  specifica¬ 
tion  is  “WaterPres  <  Low” .  Events  are  denoted  by  the 
notation  “©T® .  Two  examples  of  events  are  the  input 
event  ©T(Block=0n)  (the  operator  turns  Block  from 
Off  to  On)  and  the  conditioned  event  ©T(Block=0n) 


WHEN  WaterPres  <  Low  (tlie  operator  turns  Block 
to  On  when  water  pressure  is  below  Low). 

SCR  Tables.  The  A-7  requirements  document  [15] 
introduced  a  special  tabular  notation  for  writing  spec¬ 
ifications.  The  tabular  notation  facilitates  industrial 
application  of  the  SCR  method:  Not  only  do  engi¬ 
neers  find  tables  easy  to  understand  and  to  develop; 
in  addition,  tables  can  describe  large  quantities  of  re¬ 
quirements  data  concisely.  Among  the  tables  in  SCR 
specifications  are  condition  tables,  event  tables,  and 
mode  transition  tables.  Each  table  defines  a  function.2 
A  condition  table  describes  an  output  variable  or  term 
as  a  function  of  a  mode  and  a  condition;  an  event  ta¬ 
ble  describes  either  as  a  function  of  a  mode  and  an 
event.  A  mode  transition  table  describes  a  mode  as  a 
function  of  another  mode  and  an  event. 

While  condition  tables  define  total  functions,  event 
tables  and  mode  transition  tables  may  define  partial 
functions,  because  some  events  cannot  occur  when 
certain  conditions  are  true.  For  example,  in  the 
above  system,  the  event  @T(Pressure=High)  WHEN 
Pressure=TooLow  cannot  occur,  because  starting  from 
TooLow,  the  system  can  only  enter  Permitted  when  a 
state  transition  occurs. 

Tables  1-3,  each  constructed  with  our  toolset,  are 
part  of  REQ,  the  system  requirements  specification 
for  the  above  control  system.  The  tables  use  the  SCR 
bracketing  notation  to  indicate  the  “class”  of  an  ob¬ 
ject  (e.g.,  **. . .  **  for  a  mode  class,  *. . .  *  for  a  mode, 
%. . .  %  for  a  monitored  variable,  %%. . .  %%  for  a  con¬ 
trolled  va.rable,  !. . . !  for  a  term,  and  I. .  ,1  for  a,  non¬ 
numeric  value).  Future  versions  of  the  toolset  will  al¬ 
low  the  user  to  change  or  omit  this  notation. 

Table  1  is  a  mode  transition  table  describing  the 
mode  class  Pressure  as  a  function  of  the  current  mode 
and  the  monitored  variable  WaterPres.  Table  2  is  an 
event  table  describing  the  term  Overridden  as  a  func¬ 
tion  of  Pressure,  Block,  and  Reset.  Table  3  is  a  con¬ 
dition  table  describing  the  controlled  variable  Safety 
Injection  as  a  function  of  Pressure  and  Overridden. 
Table  3  states,  “If  Pressure  is  High  or  Permitted  or 
if  Pressure  is  TooLow  and  Overridden  is  true,  then 
Safety  Injection  is  Off;  if  Pressure  is  TooLow  and 
Overridden  is  false,  then  Safety  Injection  is  On.” 
The  notation  “@T(Inmode)”  in  a  row  of  an  event  ta¬ 
ble  describes  system  entry  into  the  mode  in  that  row; 
for  example,  “@T(Inmode)”  in  the  first  row  of  Table  2 
means,  “If  the  system  enters  High,  then  Overridden 
becomes  false." 
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Events 

Source  Mode 


Table  1:  Mode  Transition  Table  for  Pressure. 


♦TooLow# 

@T(2UaterPres2  >= 
$Low$> 

♦Permitted# 

@T<2UaterPres2  < 
$Low$) 

♦Permitted# 

@T(50laterPres2  >= 
$Permit$) 

♦High* 

GT(2UaterPres2  < 
$Permit$) 

Destination  Mode 


♦Permitted# 

♦TooLow# 

♦High# 

♦Permitted# 

Name: 

Class: 


(Overridden! 


Term 


Table  Type: 
Mode  Class: 


Event 

♦•Pressure** 


Events 

Modes 


♦High* 

Never 

@T< Inmode) 

♦TooLow#, 

♦Permitted# 

GT(2Block2=$0N$) 

WHEN  ZResetZ  =  $0FF$ 

@T< Inmode)  OR 
GT<2Reset2  =  $0N$) 

[Overridden!  = 

$TRUE$ 

$FALSE$ 

Table  2:  Event  Table  for  Overridden. 
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2  Although  SCR  specifications  can  be  nondeterministic,  our 
initial  model  is  restricted  to  deterministic  systems. 


Table  3:  Condition  Table  for  Safety  Injection. 


3  Formal  Requirements  Model 

Although  earlier  requirements  models,  namely, 
Faulk’s  automaton  model  [7],  the  model  underlying 
van  Schouwen’s  specification  [24,  25],  and  the  Four- 
Variable  Model,  define  some  aspects  of  the  SCR  re¬ 
quirements  method,  these  models  are  too  abstract  to 
provide  a  formal  basis  for  our  tools.  To  provide  a 
precise  and  detailed  semantics  for  the  SCR  method, 
our  model  represents  the  system  to  be  built  as  a  fi¬ 
nite  state  automaton  and  describes  the  input  and  out¬ 
put  variables,  conditions,  events,  and  other  constructs 
that  make  up  an  SCR  specification  in  terms  of  that 
automaton.  Our  automaton  model  is  a  special  case 
of  the  Four  Variable  Model.  One  significant  difference 
is  that  the  Four  Variable  Model  represents  naturally 
continuous  environmental  quantities,  such  as  pressure 
and  temperature,  as  continuous  variables,  whereas  our 
model  represents  these  quantities  as  discrete  variables. 

Our  requirements  model  defines  sets  of  modes,  en¬ 
tity  names,  values,  and  data  types  and  a  special  func¬ 
tion  TY,  which  maps  an  entity  to  its  legal  values.  The 
model  defines  system  state  in  terms  of  the  entities,  a 
condition  as  a  predicate  on  the  system  state,  and  an  in¬ 
put  event  as  a  change  in  an  input  variable  that  triggers 
a  new  system  state.  It  then  shows  how  a  set  of  func¬ 
tions,  called  table  functions,  can  be  derived  from  the 
SCR  tables.  These  table  functions  define  the  trans¬ 
form  T,  a  special  case  of  REQ  (and  SOFTREQ),  which 
maps  the  current  state  and  an  input  event  to  a  new 
state.  We  present  below  excerpts  from  our  require¬ 
ments  model  [12]  along  with  examples  taken  from  the 
system  requirements  specification  for  the  simple  con¬ 
trol  system  introduced  above. 

System  State.  We  assume  the  existence  of  the  fol¬ 
lowing  sets. 

•  MS  is  the  union  of  N  pairwise  disjoint  sets,  called 
mode  classes.  Each  member  of  a  mode  class  is 
called  a  mode. 

•  TS  is  a  union  of  data  types,  where  each  type  is  a 
nonempty  set  of  values. 

•  VS  =  MSU  TS  is  the  set  of  entity  values. 

•  RF  is  a  set  of  entity  names  r.  RF  is  partitioned 
into  four  subsets:  MR,  the  set  of  mode  class 
names;  IR,  the  set  of  input  variable  names;  GR, 
the  set  of  term  names;  and  OR,  the  set  of  output 
variable  names.  For  all  r  £  RF,  TY(r)  C  VS  is 
the  type  of  the  entity  named  r. 

A  system  state  s  is  a  function  that  maps  each  entity 
name  r  in  RF  to  a  value.  More  precisely,  for  all  r  £  RF: 


s(r)  =  v,  where  v  £  TY(r).  Thus,  by  assumption,  in 
any  state  s,  the  system  is  in  exactly  one  mode  from 
each  mode  class,  and  each  entity  has  a  unique  value. 

Example.  In  the  sample  system,  the  set  of  entity 
names  RF  is  defined  by 

RF  =  {Block,  Reset,  WaterPres,  Pressure, 

Saf etylnjection,  Overridden}. 

The  type  definitions  include 

TY(Pressure)  =  {TooLow,  Permitted,  High} 
TY(WaterPres)  =  {0,  1,  2,  •  •  •  ,  2000} 

TY(Overridden)  =  {true,  false } 

TY(Block)  =  {On,  Off}. 

Conditions.  Conditions  are  defined  on  the  values  of 
entities  in  RF.  A  simple  condition  is  true,  false,  or 
a  logical  statement  r  ©  v,  where  r  £  RF  is  an  entity 
name,  ©  £  {=,  y^,  >,  <,  >,  <}  is  a  relational  operator, 
and  v  £  TY(r)  is  a  constant  value.3  A  condition  is  a 
logical  statement  composed  of  simple  conditions  con¬ 
nected  in  the  standard  way  by  the  logical  connectives 
A,  V,  and  NOT. 

System  (Software  System).  A  system  ( software 
system )  Y  is  a  4-tuple,  Y  =  (Em ,  S,  so,  T),  where 

•  Em  is  a  set  of  input  events.  A  primitive  event 
is  denoted  as  @T(r  =  v),  where  r  is  an  entity  in 
RF  and  v  £  TY(r).  An  input  event  is  a  primi¬ 
tive  event  @T(r  =  v),  where  r  £  IR  is  an  input 
variable. 

•  S  is  the  set  of  possible  system  states. 

•  so  is  a  special  state  called  the  initial  state. 

•  T  is  the  system  transform,  i.e. ,  a  function  from 
Em  x  S  into  S. 

Events.  In  addition  to  denoting  primitive  events, 
the  “@T”  notation  also  denotes  basic  and  conditioned 
events.  A  basic  event  is  denoted  as  @T(c),  where  c  is 
any  simple  condition.  A  simple  conditioned  event  is 
denoted  as  @T(c)  WHEN  d,  where  @T(c)  is  a  basic 
event  and  d  is  a  simple  condition  or  a  conjunction  of 
simple  conditions.  Any  basic  event  @T(c)  can  be  ex¬ 
pressed  as  the  simple  conditioned  event  @T(c)  WHEN 
true.  A  conditioned  event  e  is  composed  of  simple  con¬ 
ditioned  events  connected  by  the  logical  connectors  A 
and  V. 

3  Here  as  well  as  elsewhere  in  the  formal  model,  v  is  defined  as 
a  constant  to  keep  the  notation  simple.  Our  formal  model  even¬ 
tually  generalizes  this  definition:  v  may  be  a  function  defined 
on  entities. 


The  logical  statement  represented  by  a  simple  con¬ 
ditioned  event  is  defined  by 

@T(c)  WHEN  d  =  NOT  c  Ac' Ad,  (1) 

where  the  unprimed  version  of  condition  c  denotes  c 
in  the  old  state  and  the  primed  version  denotes  c  in 
the  new  state.  Given  c  =  r  ©  v,  we  define  c'  as  c'  = 
(r  ©  v)'  =  r'  ©  v.  Based  on  these  definitions  and  the 
standard  predicate  calculus,  any  conditioned  event  can 
be  expressed  as  a  logical  statement. 

Example.  Applying  the  definition  in  (1),  the  condi¬ 
tioned  event  @T(Block=0n)  WHEN  Reset=0ff  can 
be  rewritten  as  Block'  =  On  A  Block  On  A  Reset  = 
Off.  This  event  occurs  if  both  Block  and  Reset  are 
Off  in  the  old  state  and  Block  is  On  in  the  new  state. 


a  term,  or  a  mode  class  ry.  Each  entity  ry  defined 
by  a  table  is  associated  with  exactly  one  mode  class, 
Mj,  1  <  i  <  tV.  To  represent  the  relation  between 
an  entity  and  a  mode  class,  we  define  a  function  p, 
where  p(i)  =  j  iff  entity  ry  is  associated  with  mode 
class  Mj.  Using  this  notation,  M^j  denotes  the  mode 
class  associated  with  entity  ry. 

Example.  The  only  mode  class  is  Pressure.  Hence, 
N  =  1  and  M i  =  Pressure.  Because  all  three  enti¬ 
ties  defined  by  tables,  namely,  r 4  =  Pressure,  = 
Overridden,  and  rg  =  Saf etylnj ection,  are  func¬ 
tions  of  Pressure,  we  have  p( 4)  =  p(5)  =  p(6)  =  1. 

Presented  below  for  condition,  event,  and  mode  tran¬ 
sition  tables  is  a  typical  format  and  a  description  of 
how  the  table  function  is  derived  from  a  given  table. 


Ordering  the  Entities.  To  compute  the  value  of  an 
entity  in  the  new  state,  the  transform  function  may 
use  the  values  of  entities  in  both  the  old  state  and  the 
new  state.  To  describe  the  entities  needed  in  the  new 
state,  each  entity  r  is  associated  with  a  subset  of  RF 
called  the  new  state  dependencies  set.  Given  entities 
r  and  f  in  RF ,  we  say  that  r  depends  directly  on  f  if 
f  is  in  r’s  new  state  dependencies  set.  The  “depends 
directly  on”  relation  imposes  a  partial  ordering  on  the 
set  RF .  Thus,  the  entities  in  RF  can  be  ordered  as  a 
sequence  R,  where  for  all  i  and  j  such  that  ry  and  ry 
belong  to  R,  ry  depends  directly  on  ry  implies  that  ry 
follows  rj  in  R  (that  is,  i  >  j).  The  new  state  depen¬ 
dencies  set  for  entity  ry  in  R  is  denoted  as  Df . 

Example.  The  condition  table  in  Table  3  shows 
that  the  controlled  variable  Saf  etylnj  ection  de¬ 
pends  on  two  entities  in  the  new  state,  the  mode  class 
Pressure  and  the  term  Overridden.  Hence,  the  new 
state  dependencies  set  for  Saf  etylnj  ection  contains 
Pressure  and  Overridden.  The  partial  ordering  of 
the  entities  based  on  dependencies  in  the  new  state  is 
determined  as  follows:  The  three  monitored  variables 
are  first  because  they  only  depend  on  changes  in  the 
environment.  Next  is  the  mode  class  Pressure,  which 
depends  on  WaterPres.  Next  is  the  term  Overridden, 
which  depends  on  Pressure  and  two  monitored  vari¬ 
ables,  Block  and  Reset.  The  last  entity  in  the  partial 
ordering  is  Saf  etylnj  ection.  A  sequence  R  satisfy¬ 
ing  this  partial  ordering  is 

R  =  <  WaterPres,  Block,  Reset,  Pressure, 

Overridden,  Saf etylnjection >  . 

In  sequence  R,  Saf  etylnj  ection  =  r§.  Its  new  state 
dependencies  set  is  Df  =  {Pressure,  Overridden}. 

Table  Functions.  Each  SCR  table  describes  a  table 
function,  called  E),  which  defines  an  output  variable, 


Modes 

Conditions 

mi 

Cl,l 

Cl, 2 

Cl  ,p 

m2 

C2,l 

C  2,2 

to 

mn 

Cn,  1 

Cn,2 

Cn,p 

Ti 

Vl 

v2 

Vp 

Table  4:  Condition  Table — Typical  Format. 

Condition  Tables.  Table  4  shows  a  typical  format 
for  a  condition  table  with  n  +  1  rows  and  p+ 1  columns. 
Each  condition  table  describes  an  output  variable  or 
term  ry  as  a  relation  pi  defined  on  modes,  conditions, 
and  values.  More  precisely,  pi  =  {(mj  ,  c y ; ,  Vk)  E 
(j)  x  C'i  x  TY(ri)},  where  C'i  is  a  set  of  conditions 
defined  on  entities  in  RF.  pi  has  the  following  four 
properties: 

1.  The  nij  and  the  Vk  are  unique. 

2.  U f=1m3  =  Afjyy  (All  modes  are  included). 

3.  For  all  j:  V^=1Cj,k  =  true  (Coverage:  The  disjunction 
of  the  conditions  in  each  row  of  the  table  is  true). 

4.  For  all  j,  k,l,  k  l :  c3tk  A  c3j  =  false  (Disjointness: 

The  conjunction  of  any  pair  of  conditions  in  a  row  of 
the  table  is  false). 

These  properties  guarantee  that  pi  is  a  function. 

To  make  explicit  entity  ry’  s  dependencies  on  other 
entities,  we  consider  an  alternate  form  E;  of  the  func¬ 
tion  pi.  To  define  E;,  we  require  the  new  state  depen¬ 
dencies  set,  Df  =  {yiti,yit2,  ••  where  r/yi  is 

the  entity  name  for  the  associated  mode  class.  Based 
on  Df  and  pi,  we  define  E;  as 


Fi(yi 


>  Vt,nt  )  —  \ 


Vi 

V2 


if  V"=1  (y,,i  =m3  A  Cj,i) 
if  V"=1  (y,,i  =  m3  A  Cj,2) 


l.  vp  if  V”=1  (y,,i  =  m3  A  cj,p). 


The  function  F{  is  called  a  condition  table  function. 
The  four  properties  guarantee  that  F{  is  total. 

Example.  Based  on  the  new  state  dependencies  set  Eg 
and  Table  3,  the  condition  table  function  for  Safety 
Injection,  denoted  Fq,  is  defined  by 

Saf etylnjection  =  ^(Pressure,  Overridden)  = 

Off  if  Pressure  =  High  V  Pressure  =  Permitted  V 
(Pressure  =  TooLow  A  Overridden  =  true ) 
On  if  Pressure  =  TooLow  A  Overridden  =  false 


Modes 

Events 

mi 

ei,i 

ei,2 

Cl  }p 

m2 

e2,i 

e2,2 

C2  ,p 

mn 

1 

Cn,  2 

&n,p 

Ti 

Vl 

v2 

Vp 

Table  5:  Event  Table — Typical  Format. 

Event  Tables.  Table  5  illustrates  a  typical  format  for 
an  event  table  with  n  +  1  rows  andp+1  columns.  Each 
event  table  describes  an  output  variable  or  term  r;  as 
a  relation  pi  between  modes,  conditioned  events,  and 
values,  i.e.,  ^  =  {(mj  ,ejtk,vk)  £  M^yxEiX  TY(ri)}, 
where  E{  is  a  set  of  conditioned  events  defined  on  en¬ 
tities  in  RF.  pi  has  the  following  two  properties: 

f.  The  nij  and  the  vu  are  unique. 

2.  For  all  j,  k,l,  k  ^  l:  ehu  A  eyi  =  false  (Disjointness: 
The  conjunction  of  each  pair  of  events  in  a  row  of  the 
table  is  false). 

These  properties  and  assumptions  on  input  events 
guarantee  that  pi  is  a  function.  As  with  condition 
tables,  we  make  explicit  ry’s  dependency  on  other  en¬ 
tities  by  defining  an  alternate  form  F{  of  the  function 
Pi.  To  define  E),  we  require  both  the  new  state  de¬ 
pendencies  set  E"  and  an  old  state  dependencies  set 
D°  =  {xit i,  Xit2,  •  •  • ,  where  D°  C  RF  contains 

the  entities  needed  in  the  old  state  to  compute  r;  and 
Xiti  is  the  entity  name  for  the  associated  mode  class. 
Based  on  D° ,  E",  and  pi,  F{  is  defined  by 

Fl(xl> i , . . . ,  xl>rril ,  2A1, . . . ,  yt<ni)  = 

'  v\  if  V"=1  (x8ii  =mj  A  ej,i) 
v2  if  V"=1  (x8ii  =mj  A  eJi2) 

<  . 

.  Up  if  (ryi — n A  ejtp). 

The  function  F{  is  called  an  event  table  function. 

Example.  Using  Table  2,  the  old  and  new  de¬ 

pendencies  sets  for  the  event  table  Overridden 
can  be  derived.  These  are  D g  =  Eg  = 


{Block,  Reset,  Pressure}.  Given  Eg ,  Eg  ,  and  Ta¬ 
ble  2,  the  event  table  function  for  Overridden  is  de¬ 
fined  by 
Overridden  = 

f*5(Block,  Reset,  Pressure,  Block',  Reset',  Pressure'}  = 

true  if  (Pressure  =  TooLow  A  Block'  =  On  A 
Block  =  Off  A  Reset  =  Off)  V 
(Pressure  =  Perm.  A  Block'  =  On  A 
Block  =  Off  A  Reset  =  Off) 

false  if  (Pressure  =  TooLow  A  Reset'  =  On  A 
Reset  =  Off)  V 

(Pressure  =  Perm.  A  Reset'  =  On  A 
Reset  =  Off)  V 

(Pressure'  =  High  A  Pressure  ^  High)  V 
(Pressure'  =  TooLow  A  Pressure^TooLow) 
(Pressure' =  Perm.  A  Pressure  ^  Perm.) 


Old  Mode 

Event 

New  Mode 

771 1 

el,l 

ml,l 

el,2 

m1}2 

ei  Ai 

mn 

en,  1 

rMn,l 

en,  2 

mn>2 

en,kn 

mn,kn 

Table  6:  Mode  Transition  Table — Typical  Format. 

Mode  Transition  Tables.  Table  6  shows  a  typical 
format  for  a  mode  transition  table  for  an  entity  r; 
that  names  a  mode  class  M^yy  The  table  describes 
ri  as  a  relation  pi  =  {(raj ,  ejy,  rrijy)  £  x  E{  x 

where  E{  is  a  set  of  conditioned  events  defined 
on  entities  in  RF.  pi  has  the  following  four  properties: 

1.  The  nij  are  unique. 

2.  For  all  k  ^  k' ,  mJ] k  ^  m-j.k'i  and  for  all  j  and  for  all 
k,  nij  mJtk- 

3.  For  all  j,k,k',  k  ^  k e3ik  A  eJty  =  false  (Disjoint¬ 
ness:  The  conjunction  of  any  pair  of  conditioned 
events  in  a  row  of  the  table  is  false). 

4.  For  all  m  £  Myy,  there  exists  j  such  that  mj  =  m  or 
there  exist  j  and  k  such  that  mJtk  =  m  (Each  mode  in 
the  mode  class  is  in  either  pf  s  domain  or  its  image). 

These  properties  and  assumptions  on  input  events 
guarantee  that  F{  is  a  function.  It  is  easy  to  show 
that  a  mode  transition  table  with  the  format  shown 
in  Table  6  can  be  expressed  in  the  format  shown  for 
an  event  table.  Hence,  a  mode  transition  table  can  be 
expressed  as  an  event  table  function  E). 

Example.  Based  on  Table  1,  the  old  and  new  de¬ 
pendencies  sets  for  the  mode  class  Pressure  are  de¬ 
fined  by  D°  =  {WaterPres,  Pressure}  and  E"  = 


{WaterPres}.  Given  D°  y  D ”,  and  Table  1,  the  table 
function  for  Pressure  is  defined  by 
Pressure7  = 

^(Pressure,  WaterPres,  WaterPres7}  = 

'  TooLow  if  Pressure  =  Perm.  A  WaterPres7  <  Low  A 
WaterPres  ^  Low 

High  if  Pressure  =  Perm.  A  WaterPres7  >  Permit  A 
WaterPres  ^  Permit 

Perm.  if  (Pressure  =  TooLow  A  WaterPres7  >  Low  A 
WaterPres  ^  Low)  V 

(Pressure  =  High  A  WaterPres7  <  Permit  A 
,  WaterPres  ^  Permit). 

4  Specification  Editor 


initial  value.  For  each  term  and  monitored  and  con¬ 
trolled  variable  in  the  specification,  the  variable  dic¬ 
tionary  lists  the  variable’s  type,  initial  value,  and  ac¬ 
curacy  requirements. 


Figure  4:  Constant  Dictionary. 


hirRrt|!lvjiprtj|in-&p¥!  ■  " v r * ■  Milliaw 


To  create,  modify,  or  display  a  specification,  the 
user  invokes  the  specification  editor.  As  illustrated 
in  Figure  3,  the  editor  lists  the  tables  and  dictionar¬ 
ies  that  make  up  a,  specification  in  a  window  labeled 
“Specification  Contents”.  The  tables  are  organized 
into  event,  mode  transition,  and  condition  tables.  By 
double  clicking  on  any  table  class  listed  in  the  Spec¬ 
ification  Contents,  e.g.,  “Event.  Table”,  the  user  can 
list  all  tables  of  that  class  in  the  specification.  In  the 
example  shown  in  Figure  3,  only  a  single  event  table 
exists  -  the  one  defining  the  term  lOverridden!.  Dou¬ 
ble  clicking  on  “lOverridden!”  displays  Table  2. 

i~Tj  Safetylnjection.Spec  :  Specification  Contents 


Specification  Edit  Tools  Help 


Specification  Contents: 


I  went  Table 


lOverridden!  Table 
Mode  Transition  Table 
Condition  Table 
Type  Dictionary 
Mode  Class  Dictionary 
Constant  Dictionary 
Variable  Dictionary 

'j _ m 

_ 

Figure  3:  Contents  of  a  Specification. 

Each  specification  contains  four  dictionaries:  the 
constant,  type,  mode  class,  and  variable  dictionaries. 
The  constant  dictionary  assigns  value  to  constants  in 
the  specification,  while  the  type  dictionary  describes 
each  user-defined  type  in  terms  of  some  base  type.  For 
each  mode  class  in  the  specification,  the  mode  class 
dictionary  lists  the  modes  in  the  class  along  with  its 


Figure  5:  Type  Dictionary. 


Figure  6:  Mode  Glass  Dictionary. 

Figures  4-7  show  the  constant,  type,  mode  class, 
and  variable  dictionaries  for  the  simple  safety  injec¬ 
tion  system  introduced  above.  The  constant  dictio¬ 
nary  in  Figure  4  defines  two  constants,  $’Low$=900 
and  SPermitf=1000.  The  type  dictionary  in  Figure  5 
describes  two  user-defined  types:  +  Pressure-1-,  a  non- 
negative  integer  not  exceeding  2000,  arid  -Switch  •  . 
an  enumerated  type  with  values  IQFFf  and  $ON$. 
The  mode  class  dictionary  in  Figure  6  defines  the  com¬ 
ponent  modes  and  initial  value  of  ^Pressure**,  the 
single  mode  class  in  the  specification.  Finally,  the 
variable  dictionary  in  Figure  7  defines  the  type,  initial 
value,  arid  accuracy  requirements  of  the  five  variables 
in  the  specification. 


Figure  7:  Variable  Dictionary. 


5  Consistency  Checker 

Listed  below  are  consistency  checks  derived  from 
our  formal  requirements  model.  These  checks,  which 
determine  whether  the  specifications  are  well-formed, 
are  independent  of  a  particular  system  state.  They 
are  a  form  of  static  analysis:  they  can  be  performed 
directly  on  the  information  in  the  tables  and  the  dic¬ 
tionaries.  For  example,  the  Disjointness  and  Coverage 
checks  on  a  condition  table  can  be  completed  using 
only  the  information  in  the  table  and  the  relevant  type 
definitions  in  the  type  dictionary. 

•  Proper  Syntax.  Each  component  of  the  spec¬ 
ification  lias  proper  syntax.  For  example,  each 
condition  and  event  is  well-formed. 

•  Type  Correctness.  Each  variable  has  a  defined 
type,  and  all  type  definitions  are  satisfied. 

•  Completeness  of  Variable  and  Mode  Class 

Definitions.  The  value  of  each  controlled  vari¬ 
able,  term,  and  mode  class  is  defined.  (Most 
variables  will  be  defined  by  tables,  but  standard 
mathematical  definitions  may  be  given  for  some 
controlled  variables  and  terms.) 

•  Reachability.  Every  mode  in  a  mode  class  is 
reachable.  (This  property  can  be  easily  checked 
by  analyzing  the  mode  transition  tables.) 

•  Initial  Values.  Initial  values  are  provided  for  all 
mode  classes,  monitored  variables,  and  all  terms 
and  controlled  variables  not  defined  by  condition 
tables.  (Initial  values  are  not  needed  for  variables 
defined  by  condition  tables,  since  they  can  be  de¬ 
rived  from  the  tables.  If  initial  values  are  pro¬ 


vided,  they  must  be  consistent  with  the  condition 
table  definitions.) 

•  Disjointness.  To  make  the  specifications  deter¬ 
ministic,  each  condition,  event,  and  mode  tran¬ 
sition  table  table  must  satisfy  the  Disjointness 
property.  That  is,  in  a  given  state,  each  controlled 
variable  and  term  has  a  unique  value,  and  if  a 
state  transition  occurs,  the  new  state  is  unique. 

•  Coverage.  Each  condition  table  satisfies  the 
Coverage  property.  That  is,  each  variable  de¬ 
scribed  by  a  condition  table  is  defined  everywhere 
in  its  domain. 

•  Lack  of  Circularity.  No  circular  dependencies 
exist . 

Clearly,  the  user  must  invoke  some  checks  before  oth¬ 
ers.  For  example,  checks  for  proper  syntax  must  pre¬ 
cede  type  checking,  and  type  checking  should  precede 
checks  that  the  Coverage  property  is  satisfied. 

A  prototype  consistency  checker  that  performs 
most  of  the  above  checks  lias  been  implemented.  The 
user  may  apply  the  consistency  checker  either  to  an 
individual  table  or  to  selected  components  of  the  com¬ 
plete  specification.  In  the  first  two  examples  included 
in  this  section,  consistency  checking  was  applied  to  an 
individual  table  (see  Figures  8  and  9).  In  the  third, 
“All  Checks”  were  applied  to  the  complete  specifica¬ 
tion  (see  Figure  10). 

Examples.  Figure  8  shows  the  results  of  applying 
consistency  checking  to  an  erroneous  version  of  the 
mode  transition  table  in  Table  1.  The  consistency 
checker  finds  two  type  errors:  In  the  first  column  of 
the  table’s  first  and  second  rows,  the  mode  names  are 


Figure  8:  Type  Errors  in  a  Mode  Transition  Table. 
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Figure  9:  Coverage  and  Disjointness  Errors  in  a.  Condition  Table. 


misspelled  (i.e. ,  “ToLow”  instead  of  “TooLow”  and 
“Permit”  instead  of  “Permitted”  ) .  By  double  clicking 
on  each  error  description  in  the  Results  box  of  the  CC 
Checker,  the  user  can  localize  the  error.  For  exam¬ 
ple,  in  Figure  8,  the  user  double  clicked  on  the  first 
error  listed;  to  indicate  the  corresponding  type  error, 
the  simulator  highlights  “ToLow”  in  row  1  of  the  table 
defining  **Pressure**. 

Shown  in  Figure  9  is  a  variation  of  Table  3,  which 
omits  the  “NOT”  in  the  rightmost  column  of  the  sec¬ 
ond  row.  Checking  this  condition  table  for  consistency 
reveals  two  errors:  The  table’s  second  row  violates 
both  Coverage  (Overridden  V  Overridden  yl  true) 
and  Disjointness  (Overridden  A  Overridden  yl  false). 
Double  clicking  on  an  error  description  in  the  Results 
box  of  the  Consistency  Checker  will  display  the  ta¬ 
ble  in  which  the  error  occurs  with  the  error’s  location 
highlighted  (see  row  2  of  the  condition  table  in  Fig¬ 
ure  9).  In  the  case  of  Disjointness,  the  tool  highlights 
the  two  overlapping  table  entries.  In  the  case  of  Cov¬ 
erage,  the  tool  highlights  the  row  that  is  in  error. 


Disjointness,  the  second  property  required  of  event 
tables,  is  violated  if  two  events  in  a  row,  say  e  and 
eh  overlap,  i.e.,  e  A  e'  yl  false.  Figure  10  contains  a 
variation  of  the  event  table  in  Table  2.  Running  the 
consistency  checker  detects  a  Disjointness  error. 

In  checking  for  Disjointness,  the  consistency 
checker  evaluates  the  expression,  [<S?T(Block  =  On) 
WHEN  Reset  =  Off]  A  [@T(Block  =  On)  V 
@T(Reset  =  On)].  Rewriting  this  expression 

as  a  disjunction  produces  [<®T(Block=0n)  WHEN 
Reset=0ff  A  <<IT(Block=0n)]  V  [@T(Block=0n) 
WHEN  Reset=0ff  A  @T(Reset=0n)].  Apply¬ 
ing  [1]  to  the  first  clause  of  the  disjunction,  we 
have  [Block'  =0n  A  Block=0ff  A  Reset=0ff]  A 
[Block'  =0n  A  Block=0ff].  This  simplifies  to 
Block'  =0n  A  Block=0ff  A  Reset=0ff.  Because 
this  expression  does  not  equal  false ,  the  specified  be¬ 
havior  is  nondeterministic.  This  means  that,  if  in 
TooLow  or  Permitted  mode  the  operator  turns  Block 
on  when  Reset  is  off,  the  system  may  nondeterminis- 
tically  change  Overridden  to  true  or  to  false. 


HMip 


lOrrfirlHripn' 


Table  Edit  Vfey  T**ls 


EorelvlMjecilPflSiMt :  CC  Ch*  cfcp-r 


fliHi:k+T  lni'l, 


Swoflrwan  Ctgrriprats; 

Had*  Cl  ici  liciicrw^j 
C-xibL«iL  llctlcnry 
Va-l-djla  Jl'-tlunary 
hPf-gssm^m  Til  Ip 
IttMhFIdfai1  Tot'lc 

Table 


T 


mailli 


4t(  ClirriB 


jymj.'H 


rypp 


D'lijalnhness 


■Luvhir-J'jy 


ErrCn  In  Ifihrtff'ldcfciil 

UBEa 

6 p¥*-a  in  cr5.sff«y_lru«uc^S' 


Figure  10:  Disjointness  Error  in  an  Event  Table. 


6  Simulator 

In  a  typical  session  with  the  simulator,  the  user 
begins  with  some  “starting”  state,  that  is,  either  the 
initial  state  or  a  state  he  defines.4  To  start  a  simula¬ 
tion,  the  user  enters  a  sequence  of  one  or  more  input 
events.  To  process  each  input  event  and  thus  simu¬ 
late  system  execution,  the  user  clicks  on  the  Step  But¬ 
ton  (see  the  middle  of  Figure  11),  and  the  simulator 
processes  the  next  input  event  in  the  sequence.  To 
compute  each  new  state  from  an  input  event  and  the 
current  state,  the  simulator  applies  T,  the  transform 
(i.e.,  next-state)  function  of  our  requirements  model. 

The  simulator  displays  each  system  state  in  a  win¬ 
dow  called  the  Simulator  Display  (see  Figure  11).  As 
each  new  state  is  computed,  the  simulator  updates  the 
Display  window  to  reflect  the  new  state.  The  simulator 
also  supports  a,  second  window,  called  the  Log  window 
(see  Figure  12).  The  Log  shows  the  state  history  be¬ 
ginning  with  the  “starting”  state,  organized  into  Mon¬ 
itored  Variables  and  Dependent  Variables.  In  the  Log, 
the  starting  state  is  displayed  in  full;  for  each  subse¬ 
quent  state,  the  Log  lists  the  input  event  that  caused 
the  transition  along  with  each  mode  class,  term,  and 
controlled  variable  whose  value  has  changed. 

In  the  example  shown  in  Figure  11,  the  user  has 
entered  four  events  in  the  “Pending  Events”  area  of 
the  Display  window.  The  upper  portion  of  the  Dis¬ 

4  Note  that  a  starting  state  that  differs  from  the  initial  state 
may  not  be  reachable. 


play  window  in  Figure  11  shows  the  system  state  after 
the  simulator  has  processed  three  of  the  four  pending 
events  (i.e.,  the  user  has  clicked  on  the  Step  button 
three  times).  The  Log  in  Figure  12  shows  the  system 
history  after  all  four  events  have  been  processed. 

To  display  the  rule  that  caused  a  given  entity  to 
change  value,  the  user  double  clicks  on  the  entity  and 
its  value  in  the  Log.  The  simulator  then  displays  the 
table  that  defines  the  variable,  highlighting  the  rule 
that  led  to  the  change.  For  example,  double  click¬ 
ing  on  the  expression  “%%SafetyInjection%%=$ON$” 
near  the  bottom  of  the  Log  in  Figure  12  will  cause 
the  simulator  to  display  the  table,  shown  in  Figure  12 
on  the  right,  that  caused  Saf  etylnj  ection  to  change 
from  Off  to  On.  The  simulator  also  highlights  the  rule 
that  produced  the  change.  In  Figure  12,  the  high¬ 
lighted  rule  is  “If  Pressure  is  TooLow  and  Overridden 
is  false,  then  Saf  etylnj  ection  is  On.” 

7  Verifier. 

We  are  investigating  the  design  of  a  state  explo¬ 
ration  tool  that  verifies  application  properties  mechan¬ 
ically.  Such  a  tool  analyzes  all  states  of  a  Unite  state 
machine  model  of  a  system  to  determine  whether  they 
satisfy  selected  properties.  Our  state-based  require¬ 
ments  model  and  its  transform  function  T  provide  a 
basis  for  building  such  a  tool  for  verifying  requirements 
specifications. 


Figure  11:  Simulator  Display  Showing  Four  Pending  Events. 
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Figure  12:  Simulator  Log  and  Table  with  Rule  Highlighted. 


We  are  also  investigating  the  linkage  of  our  toolset 
with  a  mechanical  proof  system,  such  as  EVES  [17] 
or  PVS  [20],  to  support  another  form  of  verification — 
theorem  proving.  Such  a  tool  can  check  formal  proofs 
that  the  specifications  satisfy  properties  of  interest. 
Proofs  would  be  done  by  hand  using  deductive  rea¬ 
soning  (see,  e.g.,  [11])  and  checked  mechanically  using 
the  proof  system. 

To  illustrate  application  properties  we  wish  to  ver¬ 
ify,  some  examples  are  listed.  Each  is  a  property  of 
the  simple  control  system  described  above. 

1,  If  Block  is  Off  and  Pressure  is  TooLow,  then 
Safetylnjectionis  On. 

2.  If  Block  is  On  and  Reset  is  Off,  then 
Safetylnjectionis  Off. 


3.  If  WaterPres  is  greater  than  Low  and  WaterPres  is  less 
than  Permit,  then  Pressure  is  Permitted. 

4.  If  WaterPres7  is  greater  than  or  equal  to  Low  and 
Pressure  is  TooLow,  then  Pressure7  is  not  equal  to 
High. 

5.  If  @T(WaterPres  <  Low)  WHEN  Block  is  Off,  then 
Saf  etylnjection7  is  On. 

8  Related  Work. 

In  a  related  effort,  Atlee  and  Gannon  used  model 
checking,  a  state  exploration  technique  pioneered  by 
Clarke  [3],  to  test  SCR  requirements  specifications  for 
application  properties  [2].  Their  tool  analyzes  proper- 


ties  defined  in  terms  of  mode  classes  and  input  vari¬ 
ables  only  (e.g.,  Properties  3  and  4  above).  Their  state 
model  is  derived  from  the  mode  transition  tables,  ex¬ 
tended  by  hand  to  incorporate  the  needed  variable  def¬ 
initions.  Such  analysis  is  significant  because  it  checks 
that  the  expressions  in  the  mode  transition  tables  cap¬ 
ture  desired  properties.  However,  our  requirements 
model  provides  the  basis  for  a  more  general  analysis: 
properties  involving  all  of  the  entities  can  be  checked 
against  a  state  machine  model  of  the  complete  specifi¬ 
cations.  That  model  is  captured  by  our  formal  defini¬ 
tions  of  system  and  the  transform  function  that  maps 
an  input  event  and  the  current  state  to  the  new  state. 

In  other  related  work,  Parnas  describes  ten  small 
theorems  related  to  his  tabular  notation  (similar  to 
other  SCR  notation)  and  challenges  the  developers  of 
automated  proof  systems  to  prove  the  theorems  [22]. 
Two  of  the  theorems,  the  Domain  Coverage  Theorem 
and  the  Disjoint  Domains  Theorem,  are  slight  vari¬ 
ations  of  our  Coverage  and  Disjointness  properties. 
SRI  researchers  accepted  Parnas’  challenge.  In  a  re¬ 
cent  paper  [23],  they  describe  the  mechanical  proof  of 
nine  of  Parnas’  theorems  using  the  “tcc-strategy”  (tec’s 
are  type-correctness  conditions)  of  their  proof  system 
PVS  [20].  Based  on  this  result,  we  are  investigating 
the  utility  of  PVS  and  other  mechanical  provers  for 
consistency  checking. 

9  Requirements  Process 

We  envision  the  following  process  for  developing  re¬ 
quirements  specifications  for  high  assurance  systems. 
Although  such  a  process  is  an  idealization  of  a  real- 
world  process,  it  shows  how  tools  such  as  ours  can  be 
used  incrementally  to  develop  high  assurance  require¬ 
ments  specifications. 

1.  A  formal  notation,  such  as  the  SCR  notation,  is  used 
to  specify  the  requirements. 

2.  An  automated  consistency  checker  tests  the  specifi¬ 
cation  for  syntax  and  type  correctness,  coverage,  de¬ 
terminism,  and  other  application-independent  prop¬ 
erties. 

3.  The  specification  is  executed  symbolically  using  a  sim¬ 
ulator  to  ensure  that  it  captures  the  customers’  intent; 
the  simulator  can  be  run  either  manually  as  described 
above,  or  automatically  using  an  input  script  (see, 
e-g-,  [4]). 

4.  In  the  later  stages  of  requirements,  mechanical  sup¬ 
port  is  used  to  analyze  the  specification  for  applica¬ 
tion  properties.  Initially,  a  small  subset  with  fixed 
parameters  and  only  a  few  states  is  extracted  from 
the  specification  and  a  state  exploration  tool  is  used. 
This  may  be  repeated,  each  time  with  a  different  or 
larger  subset.  Once  there  is  sufficient  confidence  in 


the  specification,  a  deductive  proof  system  may  be 
used  to  heip  verify  the  compiete  specification  or,  more 
iikeiy,  safety-criticai  components. 


10  Concluding  Remarks 

In  our  view,  the  use  of  properly  designed  software 
tools,  in  conjunction  with  a  formal  requirements  nota¬ 
tion,  is  an  important  step  in  developing  high  assurance 
systems.  Such  tools  can 

•  Liberate  people  to  work  on  more  creative 
tasks.  For  example,  although  consistency  checks 
are  quite  simple,  the  number  of  such  checks 
needed  in  practical  requirements  specifications 
can  be  very  large.  In  the  Darlington  plant  cer¬ 
tification,  Parnas  found  that  “reviewers  spent  too 
much  of  their  time  and  energy  checking  for  sim¬ 
ple,  application-independent  properties”  which 
distracted  them  from  the  “more  difficult,  safety¬ 
relevant  issues”  [22].  Automating  such  checks  can 
save  both  the  specifiers  and  reviewers  consider¬ 
able  effort,  thus  liberating  them  to  do  more  cre¬ 
ative  work. 

•  Perform  some  tasks  more  effectively  than 

people.  Tools  can  often  find  errors  that  people 
miss.  In  the  experiments  cited  above,  our  tools 
found  many  significant  errors  overlooked  by  two 
independent  review  teams  [13].  This  does  not  in¬ 
dicate  reviewer  incompetence  but  illustrates  in¬ 
stead  that,  for  large  specifications,  tools  are  better 
than  people  for  detecting  certain  classes  of  errors, 
such  as  missing  cases  and  nondeterminism. 

•  Increase  confidence  in  the  specification’s 
correctness.  Analyzing  the  specifications  with 
software  tools  can  increase  confidence  that  the 
specifications  capture  the  required  behavior.  By 
symbolically  executing  the  specifications  using  a 
simulator,  the  specifiers  (and  future  users)  can 
determine  whether  the  external  behavior  repre¬ 
sented  by  the  specifications  captures  their  intent. 
By  running  the  verifier,  the  specifiers  and  the  re¬ 
viewers  can  check  that  the  specification  satisfies 
critical  application  properties. 

We  expect  the  process  outlined  above,  which  uses 
formal  notation  to  specify  requirements  and  computer- 
supported  formal  analysis  to  detect  errors,  to  produce 
high  quality  requirements  specifications.  Such  specifi¬ 
cations  are  an  important  step  toward  developing  high 
assurance  systems. 
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